clang-tidy review says "All clean, LGTM! 👍"

Took a quick look on MSYS2. The /usr/bin/env workaround (running a shutil.which() on the specified interpreter) is still necessary on Windows; removing it results in "The system cannot find the file specified".

@daljit46 Do you want to make a case against the pre-existing behaviour where we ensure that executed Python scripts use the same interpreter as that currently executing, potentially overruling the system config? Otherwise I'll merge this.

I don't have strong objections against this PR.

I note that a reversion back to using /usr/bin/env seems to be the most appropriate course of action from discussion with @daljit46.

Yes, this is the expectation I have when running a script. I think it's the simplest solution and the most in line with Python's idea of venvs.
However, the author of a script is always in a better position to determine the Python versions (just like in C++ code the project author sets up the C++ standard). So if we want to have a custom logic to choose/impose the Python interpreter, I'm not opposed to it (as long as this is adequately documented).

In responding on #2261, I realised there may be an outstanding problem with this kind of solution.

One of the approaches that had been proposed earlier for controlling the Python module search environment was to have executable files where the shebang points to a softlink to Python. That softlink would reside within the MRtrix3 build / installation directory, and just point to a suitable Python version. However by invoking via that softlink, the MRtrix3 API would intrinsically be included within Python's sys.path.

Say hypothetically that a third party software uses a similar approach, but instead of the shebang pointing to a softlink, it instead points to a Python in eg. a custom Conda environment, which contains custom libraries / library versions requisite for that command. Say for instance:

#!/usr/local/fsl/bin/python

With the code in this PR, that would result in use of the current interpreter, which may cause problems for that command.

For the FSL I have installed locally, this isn't the case, they instead use eg.:

#!/usr/bin/env bash
/usr/local/fsl/bin/python -I /usr/local/fsl/bin/eddy_quad "$@"

, which would be fine. But I don't know if this is what FSL has always done, or whether any other third party piece of software could hard-code a custom Python into their shebang.

There's a possible alternative strategy that comes to mind:

• If the command is an MRtrix3 command, and it is a Python command (which is now known without even having to parse the file, CMake generates a list), then use the same interpreter as that currently running;
• If the command is a non-MRtrix3 command, make no attempt to impose the currently executing interpreter; just take the shebang and use it.

I don't recall whether there have been any historical edge cases where this would cause problems. But some of them may have had to do with malformed shebangs, which may have been resolved upstream in third-party softwares.

I'll let this simmer for a bit, but my current instinct is that this would be a better solution.